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The present invention relates to a technology for 



reducing communication load when abnormality occurs during 
communication . 

BACKGROUND OF THE INVENTION 



clients and a server are becoming a main stream in recent 
data communication. In a data communication device of this 
type, if the number of clients increases, communication load 
increases accordingly. Means and methods of minimizing 

15 communication load as much as possible are, therefore, 
strongly demanded. 

FIG. 9 is a block diagram showing the constitution 
of a conventional CORBA (Common Object Request Broker 
Architecture) communication system. CORBA is a 

20 standardization specification for connection among 
different types of devices set by the standardization group 
or OMG (Object Management Group) and is to specify various 
API (Application Program Interfaces) for establishing 
linkage protocols and distributed applications among 

25 different types of devices. 



10 



Use of data communication devices consisting of 



1 



Briefly, the CORBA is a standard technique for 
providing a mechanism for a client to access an object (e.g., 
an application program) in a server in a distributed system 
environment. Here, an object in the CORBA means an 
5 identifiably capsulate entity providing one or a plurality 
of services which can be requested from clients. 

FIG. 9 shows a CORBA communication system consisting 
of n clients 10i to 10 n and a server 20 connected to the 
clients 10i to 10 n through a network (not shown) . Each of 

10 the clients 10i to 10 n communicates with the server 20 in 
accordance with a predetermined protocol . In this protocol, 
processings including request, reply, commitment and 
rollback are generated. 

In a request processing, each of the clients 10i to 

15 10 n requests a transaction processing of the server 20 and 
the update of a database 25 in which the transaction is 
generated. A reply processing is a reply to the request 
and notified from the server 20 to each of the clients Id 
to 10 n . A commitment processing is to reflect the processing 

20 result of each of the clients 10i to 10 n on the database 
25. A rollback processing is to return the state of the 
database 25 to a state before the transaction is executed 
and to maintain consistency if the connection between one 
of the clients 10 x to 10 n and the server 20 is abnormally 

25 cut off. 



In the client 10 x , an ORB (Object Request Broker: 
communication mechanism among distributed objects) Hi is 
a software bus mediating between the client Id and the server 
20. The ORB Hi has an initial object reference including 
5 an IP address and a PORT number of the client 10i itself. 

Now, a naming service in the CORBA will be described. 
According to the naming service in the CORBA, if a client 
accesses an object, the client can do so not by the position 
of the object but by the name of the object. Due to this, 
10 it is not necessary for the client to recognize the physical 
position of the object. 

To be specific, if an object is accessed by a client, 
an object reference is generated in the server 20 and returned 
to the client, thereby providing a naming service to the 
15 client. This object reference is information for uniquely 
identifying an objects by its name. 

A request transmission section 12i has a function of 
transmitting the above-stated request to the server 20. A 
reply reception section 13i has a function of receiving a 
20 reply from the server 20. The reply is a reply to the 
above-stated request. A commitment/rollback transmission 
section 14i has a function of transmitting the above-stated 
commitment or rollback to the server 20. 

In the client 10 2 , an ORB 11 2 is a software bus mediating 
25 between the client 10 2 and the server 20 as in the case of 



the ORB Hi. This ORB 11 2 has an initial object reference 
including an IP address and a PORT number of the client 10 2 
itself. 

A request transmission section 12 2 has a function of 
5 transmitting the above-stated request to the server 20. A 
reply reception section 13 2 has a function of receiving a 
reply from the server 20. The reply is a reply to the 
above-stated request. A commitment /rollback transmission 
section 14 2 has a function of transmitting the above-stated 
10 commitment or rollback to the server 20. 

In the client 10 n , an ORB ll n is a software bus mediating 
between the client 10 n and the server 20 as in the case of 
the ORB Hi. This ORB ll n has an initial object reference 
including an IP address and a PORT number of the client 10 n 
15 itself. 

A request transmission section 12 n has a function of 
transmitting the above-stated request to the server 20. A 
reply reception section 13 n has a function of receiving a 
reply from the server 20. The reply is a reply to the 

20 above-stated request . A commitment /rollback transmission 
section 14 n has a function of transmitting the above-stated 
commitment or rollback to the server 20. 

A server 20 has a function of receiving requests from 
the clients 10i to 10 n / a function of transmitting replies 

25 to the corresponding requests to the clients 10i to 10 n , 



a function of receiving commitments from the clients 10i 
to 10 n , a function of updating the database 25 based on the 
commitments, a function of receiving rollbacks from the 
clients 10i to 10 n and a function of returning the state 
5 of the database 25 to a state before a transaction is executed 
based on the rollbacks. 

To be specific, the server 20 consists of an ORB 21, 
a request reception section 22, a reply transmission section 
23 , a commitment /rollback reception section 24 and a database 
10 25. The ORB 2 1 is a software bus mediating between the server 
20 and the clients 10i to 10 n . The request reception section 
22 has a function of receiving requests from the clients 
Id to 10 n . 

The reply transmission section 23 has a function of 
15 transmitting replies to the requests to the clients Id to 
10 n , respectively. The commitment/rollback reception 
section 24 has a function of receiving commitments from the 
clients 10i to 10 n , a function of updating the database 25 
based on the commitments, a function of receiving rollbacks 
20 from the clients 10i to 10 n and a function of returning the 
state of the database 25 to a state before a transaction 
is executed based on the rollbacks. 

How the conventional CORBA communication system works 
will be described with reference to FIG . 10. FIG. 10 is 
25 a sequence view for describing the operation of the 



conventional CORBA communication system. First, operation 
in a normal state between the client 10 n and the server 20 
will be explained. It is noted that the operation between 
each of the clients 10i to 10 n -i (not shown) and the server 
5 20 is the same as that between the client 10 n and the server 
20 to be described hereinafter. 

In a step SAl shown in FIG. 10, when the request 
transmission section 12 n of the client 10 n transmits a request, 
the request reception section 22 of the server 20 receives 

10 the request. 

Following this, in a step SA2 , when the reply- 
transmission section 23 of the server 20 transmits a reply, 
the reply reception section 13 n receives the reply. In a 
step SA3, when the commitment/rollback transmission section 

15 14 n transmits a commitment, the commitment /rollback 
reception section 24 receives the commitment. By doing so, 
the database 25 in the server 20 is updated. 

Next, operation when the connection set between the 
client 10 n and the server 20 shown in FIG. 9 is abnormally 

20 cut off will be explained. In a step SB1 shown in FIG. 10, 
when the request transmission section 12 n of the client 10 n 
transmits a request, the request reception section 22 n of 
the server 20 receives the request. Following this, in a 
step SB2 , the reply transmission section 23 of the server 

25 20 transmits a reply. 



Here, if the connection is abnormally cut off, 
transaction mismatching occurs and the reply stated above 
is not received by the reply reception section 13 n . In this 
case, in a step SB3, when the commitment /rollback 
5 transmission section 14 n transmits a rollback, the 
commitment /rollback reception section 24 receives the 
rollback. As a result, the state of the server 20 is returned 
to a state before the transaction is executed. Namely, in 
the abnormal state, the database 25 is not updated. 

10 Meanwhile, as already explained above, the 

conventional CORBA communication system requires 
communication for commitment /rollback between the clients 
10i to 10 n and the server 20 when abnormality occurs to the 
communication. Thus, the conventional CORBA communication 

15 system has a disadvantage of increasing communication load 
(transactions) if the number of clients increases. This 
disadvantage becomes a bottleneck particularly when a 
network has a low line capacity. 

2 0 SUMMARY OF THE INVENTION 

It is an object of the present invention to provide 
a method and device for data communication in which it is 
possible to reduce communication load at a time when 
abnormality occurs to communication. It is another object 

25 of this invention to provide a computer readable recording 



medium that stores a computer program which when executed 
realizes the method according to the present invention. 

The data communication device according to one aspect 
of the present invention comprises a reply unit which, if 
5 a request is issued from the external device, transmits reply 
information corresponding to the request, and stores the 
reply information in a memory; a connection monitoring unit 
which monitors connection with the external device; and a 
transmission unit which transmits the reply information 

10 corresponding to the connection and stored in the memory, 
to the external communication device if the connection is 
abnormally cut off based on a monitoring result of the 
connection monitoring unit. 

The data communication method according to another 

15 aspect of the present invention comprises a reply step of, 
if a request is issued from the external device, transmitting 
reply information corresponding to the request, and of 
storing the reply information in a memory; a connection 
monitoring step of monitoring connection with the external 

20 device; and a transmission step of transmitting the reply 
information corresponding to the connection and stored in 
the memory, to the external communication device if the 
connection is abnormally cut off based on a monitoring result 
of the connection monitoring step. 

25 The computer readable recording medium according to 



another aspect of the present invention stores a computer 
program which when executed realizes the method according 
to the present invention. 

According to the above-mentioned aspects of this 
5 invention, the reply information is transmitted to the 
external device and stored in the memory, and the reply 
information is transmitted to the external device when 
abnormality occurs to connection. Thus, compared with 
conventional rollback from the external device, the traffic 
10 of a communication line can be reduced and communication 
load can be reduced when abnormality occurs to communication . 

Other objects and features of this invention will 
become apparent from the following description with 
reference to the accompanying drawings. 

15 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram showing the constitution 
of one embodiment according to the present invention; 

FIG. 2 is a sequence view for describing the operation 
20 of the embodiment; 

FIG. 3 is a flow chart for describing the operation 
of a transaction guarantee section 44 shown in FIG. 1; 

FIG. 4 is a flow chart for describing the operation 
of transaction notification agents 34 x to 34 n shown in FIG. 
25 1; 



FIG. 5A to FIG. 5C are views showing the formats of 
reply information and connection notification information 
used in the embodiment; 

FIG. 6 is a flow chart for describing the operation 
5 of the transaction guarantee section 44 shown in FIG. 1; 

FIG. 7A and FIG. 7B are views showing the format of 
reply information used in the embodiment; 

FIG. 8 is a block diagram showing a modification of 
the embodiment; 

10 FIG. 9 is a block diagram showing the constitution 

of a conventional CORBA communication system; and 

FIG. 10 is a sequence view for describing the operation 
of the conventional CORBA communication system. 

15 DESCRIPTION OF THE PREFERRED EMBODIMENTS 

A preferred embodiment of the method and device for 
data communication according to the present invention will 
be described in detail hereinafter with reference to the 
accompanying drawings . 

20 FIG. 1 is a block diagram showing the constitution 

of one embodiment according to the present invention. FIG. 
1 shows data communication utilizing a CORBA consisting of 
n clients 30i to 30 n and a server 20 connected to the clients 
30i to 30 n through a network (not shown) . Each of the clients 

25 30]. to 30 n communicates with the server 20 in accordance 

10 



with a predetermined protocol . It should be noted here that 
the data communication system shown in FIG. 1 has no factor 
for increasing communication load of commitment /rollback 
compared with the conventional CORBA communication system 
5 (see FIG . 9) stated above. 

In the client 30i, an ORB 31i is a software bus mediating 
between the client 30i and the server 20. This ORB 31 a has 
an initial object reference including an IP address and a 
PORT number of the client 30i itself. 

10 A request transmission section 32i has a function of 

transmitting the above-stated request to the server 20. 
Here, the ORB 31i acquires a request ID for identifying the 
request at the time of transmitting the request and adds 
this request ID to the request. A reply reception section 

15 33i receives reply information 50i shown in FIG. 5A. 

This reply information 50i consists of an IP address 
( 1 ) , a PORT number ( 1 ) , a request ID ( 1 ) , a client application 
name (1) and reply data (1) . This reply information 50i 
is information transmitted f roma reply transmission section 

20 43 to be described later as a reply to the request. 

The request ID is a request ID acquired by the ORB 
31i. The client application (1) is the names of the request 
transmission section 32i and reply reception section 33i 
of the client 3d. The reply data (1) is data transmitted 

25 from the reply transmission section 43 of the server 40. 



The transaction notification agent 34i has a function 
of matching a client 30i~side transaction when connection 
is abnormally cut off, based on notification reply 
information 60 in a format shown in FIG . 5B. The notification 
5 reply information 60 consists of a request ID, a client 
application name and reply data. 

FIG. 7B shows a concrete example of the notification 
reply information 60. Notification reply information 90i 
is information transmitted from a transaction guarantee 

10 section 44 to be described later if abnormality occurs to 
the connection between the client 30i and the server 40. 
The information 90i consists of a request ID (1), a client 
application name (1) and reply data (1). This notification 
reply information 90i corresponds to the reply information 

15 50i shown in FIG. 5A. The reply notification agent 34i 
specifies a request from the notification reply information 
90i when abnormality occurs to the connection and makes 
transaction matching based on the specification result. 

In the client 30 2 , an ORB 31 2 is a software bus mediating 

20 between the client 30 2 and the server 20. This ORB 31 2 has 
an initial object reference including an IP address and a 
PORT number of the client 30 2 itself. 

A request transmission section 32 2 has a function of 
transmitting the above-stated request to the server 20. 

25 Here, the ORB 31 2 acquires a request ID for identifying the 



request at the time of transmitting the request and adds 
this request ID to the request. A reply reception section 
33 2 receives reply information 50 2 shown in FIG. 5A. 

This reply information 50 2 consists of an IP address 
5 (2), a PORT number (2), a request ID (2), a client application 
name (2) and reply data (2) . This reply information 50 2 
is information transmitted from the reply transmission 
section 43 to be described later as a reply to the request. 

The request ID is a request ID acquired by the ORB 

10 31 2 . The client application (2) is the names of the request 
transmission section 32 2 and reply reception section 33 2 
of the client 30 2 . The reply data (2) is data transmitted 
from the reply transmission section 43 of the server 40. 

The transaction notification agent 34 2 has a function 

15 of matching a client 30 2 -side transaction when connection 
is abnormally cut off, based on notification reply 
information 90 2 shown in FIG. 7B. The notification reply 
information 90 2 is information transmitted from the 
transaction guarantee section 44 to be described later if 

20 abnormality occurs to the connection between the client 30 2 
and the server 40, and consists of a request ID (2) , a client 
application name (2) and reply data (2). 

The notification reply information 90 2 corresponds 
to the reply information 50 2 shown in FIG. 5A. The 

25 transaction notification agent 34 2 specifies a request from 



the notification reply information 90 2 when abnormality 
occurs to the connection andmakes transaction matching based 
on the specification result. 

In the client 30 n , an ORB 31 n is a software bus mediating 
5 between the client 30 n and the server 20. This ORB 31 n has 
an initial object reference including an IP address and a 
PORT number of the client 30 n itself. 

A request transmission section 32 n has a function of 
transmitting the above-stated request to the server 20. 

10 Here, the ORB 31 n acquires a request ID for identifying the 
request at the time of transmitting the request and adds 
this request ID to the request. A reply reception section 
33 n receives reply information 50 n shown in FIG. 5A. 

This reply information 50 n consists of an IP address 

15 (n) , a PORT number (n) , a request ID (n) , a client application 
name (n) and reply data (n) . This reply information 50 n 
is information transmitted from the reply transmission 
section 43 to be described later as a reply to the request. 
The request ID is a request ID acquired by the ORB 

20 31 n . The client application (n) is the names of the request 
transmission section 32 n and reply reception section 33 n 
of the client 30 n . The reply data (n) is data transmitted 
from the reply transmission section 43 of the server 40. 
It is noted that reply information 80i to 80 n shown in FIG. 

25 7B may be used instead of the reply information 50i to 50 n 



shown in FIG. 5A in one embodiment. 

The transaction notification agent 34 n has a function 
of matching a client 30 n -side transaction when connection 
is abnormally cut off, based on notification reply 
5 information 90 n shown in FIG. 5B. The notification reply 
information 90 n is information transmitted from the 
transaction guarantee section 44 to be described later if 
abnormality occurs to the connection between the client 30 n 
and the server 40, and consists of a request ID (n) , a client 

10 application name (n) and reply data (n) . 

In addition, the notification reply information 90 n 
corresponds to the reply information 50 n shown in FIG. 5A. 
The transaction notification agent 34 n specifies a request 
from the notification reply information 90 n when abnormality 

15 occurs to the connection andmakes transaction matching based 
on the specification result. 

The server 40 has a function of receiving requests 
from the clients 30i to 30 n , a function of transmitting reply 
information 50i to 50 n as replies to the requests, to the 

20 clients 30i to 30 n , respectively, a function of monitoring 
connection between the server 40 and the clients 30i to 30 n 
and a function of updating a database 45. 

To be specific, the server 40 consists of an ORB 41, 
a request reception section 42, a reply transmission section 

25 43, a transaction guarantee section 44 and a database 45. 



The ORB 41 is a software bus mediating between the server 
40 and the clients 30i to 30 n . This ORB 41 has a function 
of transmitting the reply information 50i to 50 n (see FIG. 
5A) and a function of monitoring connection between the 
5 server 40 and the clients 30i to 30 n . 

Also, the ORB 41 notifies the transaction guarantee 
section 44 of connection monitoring result information 70 
in a format shown in FIG. 5C as a connection monitoring result . 
The connection monitoring result information 70 consists 

10 of a notification information type code (X'03') and a 
notification code (X' 00 or X'01') . The notification type 
code is a code for notifying that that connection was released 
The notification code is a code for notifying that connection 
was normally released or abnormally cut off when releasing 

15 the connection. 

The request reception section 42 has a function of 
receiving requests from the clients 30i to 30 n . The reply 
transmission section 43 has a function of transmitting reply 
data (see FIG. 5B) as replies to the above-stated requests 

20 to the ORB 41. The transaction guarantee section 44 has 
a function of avoiding client-side transaction mismatching 
following the abnormal cutoff of the connection and 
guaranteeing a transaction. In addition, the transaction 
guarantee section 44 has a function of transmitting 

25 notification reply information 90i to 90 n to the clients 



30i to 30 n , respectively based on the connection monitoring 
result information 70 (in case of abnormal release) from 
the ORB 41. 

Next, the operation of the above-stated embodiment 
5 will be described with reference to FIG . 2 to FIG. 7B. FIG. 
2 is a sequence view for describing the operation of the 
embodiment according to the present invention. First, 
description will be given, centering around the operation 
between the client 30 n and the server 40 in a normal state. 
10 It is noted that the operation between each of the clients 
30i to 30 n -i (not shown) and the server 40 is the same as 
that between the client 30 n and the server 40 described 
hereinafter . 

Operation in case of the normal state will now be 
15 explained. In a step SEl shown in FIG. 3, the transaction 
guarantee section 44 judges whether or not the section 44 
received reply information (see FIG. 7A) from the ORB 41 
of the server 40. If the judgment result is 'No', the 
transaction guarantee section 44 repeats the same judgment. 
20 In a step SF1 shown in FIG. 4, on the other hand, the 

transaction notification agents 34i to 34 n of the clients 
30i to 30 n judges whether or not the agent 34 n received 
notification reply information (see FIG. 7B) from the 
transaction guarantee section 44. If the judgment result 
25 is 'No' , the transaction notification agent 34 n repeats the 



same judgment. 

Here, in a step SCI shown in FIG. 2, the request 
transmission section 32 n of the client 30 n transmits a request 
to the server 40 . At this time, the ORB 31 n acquires a request 
5 ID(n) shown in FIG. 5A and adds the acquired request ID(n) 
to the request . The request (with the request ID) is received 
by the request reception section 42 of the server 40. 

In a step SC2, the reply transmission section 43 
transmits reply data (n) shown in FIG. 5A to the ORB 41. 

10 Following this, in a step SC3, the ORB 41 transmits reply 
information 50 n shown in FIG. 5A to the transaction guarantee 
section 44. This reply information 50 n is received by the 
transaction guarantee section 44. 

Thereafter, the transaction guarantee section 44 

15 determines the judgment result of the step SEl shown in FIG. 
3 as ''Yes' and stores reply information 50i in a memory (not 
shown) . In a step SE2, the transaction guarantee section 
44 judges whether or not the section 44 received connection 
monitoring result information 70 (see FIG. 5B) from the ORB 

20 41. If the judgment result is 'No', the transaction 
guarantee section 44 repeats the same judgment. 

Next, in a step SC4 shown in FIG. 2, the ORB 41 transmits 
the reply information 50 n to the reply reception section 
33 n of the client 30 n . This reply information 50 n is received 

25 by the reply reception section 33 n and then stored in the 



memory (not shown) . 

When the connection between the client 30 n and the 
server 40 is normally released, the ORB 41 transmits the 
connection monitoring result information 70 (see FIG. 5C), 
5 as a notification that the connection was normally released, 
to the transaction guarantee section 44 in a step SC6. This 
connection monitoring result information 70 (normal 
release) is received by the transaction reception section 
44 . 

10 Thereafter, the transaction guarantee section 44 

determines the judgment result of the step SE2 shown in FIG. 
3 as ^Yes' . In a step SE3, the transaction guarantee section 
44 j udges whether or not the connection was normally released 
while referring to the notification code of the received 

15 connection monitoring result information 70, and, in this 
case, determines the judgment result as ^Yes' . In a step 
SE4, the transaction guarantee section 44 destroys the reply 
information 50 n (see FIG. 5A) stored in the memory. 

Next, operation in case of the abnormal state, i.e. 

20 when connection between the client 30 n and the server 40 
shown in FIG. 1 is abnormally cut off will be explained. 
In the step SEl shown in FIG. 3, the transaction guarantee 
section 44 judges whether or not the section 44 received 
the reply information (see FIG. 7A) from the ORB 41. If 

25 the judgment result is 'No', the transaction guarantee 



section 44 repeats the same judgment. 

In the step SF1 shown in FIG. 4, on the other hand, 
the transaction notification agents 34 x to 34 n of the clients 
30i to 30 n judges whether or not the agent 34 received 
5 notification reply information (see FIG. 7B) from the 
transaction guarantee section 44. If the judgment result 
is "No' , the transaction notification agent 34 n repeats the 
same judgment. 

Here, in the step SDl shown in FIG. 2, the request 

10 transmission section 32„ of the client 30 n transmits a request . 
At this time, the ORB 31 n acquires a request ID(n) shown 
in FIG. 5A and adds the acquired request ID (n) to the request. 
The request (with the request ID) is received by the request 
reception section 42 of the server 40. 

15 In the step SD2, the reply transmission section 43 

transmits reply data (n) shown in FIG. 5A to the ORB 41. 
Following this, in the step SD3, the ORB 41 transmits reply 
information 50 n shown in FIG. 5A to the transaction guarantee 
section 44. This reply information 50 n is received by the 

20 transaction guarantee section 44. 

Thereafter, the transaction guarantee section 44 
determines the judgment result of the step SE1 shown in FIG. 
3 as A Ye s ' and stores the reply information 50i in the memory 
(not shown) . In the step SE2, the transaction guarantee 

25 section 44 judges whether or not the section 44 received 



connection monitoring result information 70 (see FIG. 5B 
from the ORB 41. If the judgment result is 'No', the 
transaction guarantee section 44 repeats the same judgment. 
Next, in the step SD4 shown in FIG. 2, the ORB 41 
5 transmits the reply information 50 n to the reply reception 
section 33 n of the client 30 n . This reply information 50 n 
is received by the reply reception section 33 n and then stored 
in the memory (not shown) . 

Here, if the connection between the client 30 n and 

10 the server 40 was abnormally cut off, the ORB 41 transmits 
the connection monitoring result information 70 (see FIG. 
5C) , as a notification that the connection was abnormally 
cut off, to the transaction guarantee section 44 in the step 
SD6. At this time, transaction mismatching occurs. The 

15 connection monitoring result information 70 (abnormal 
cutoff) is received by the transaction guarantee section 
44 . 

Thereafter, the transaction guarantee section 44 
determines the judgment result of the step SE2 shown in FIG. 

20 3 as 'Yes' . In the step SE3, the transaction guarantee 
section 44 judges whether or not the connection was normally 
released while referring to the notification code of the 
received connection monitoring result information 70, and, 
in this case, determines the judgment result as 'No' . In 

25 the step SE5, the transaction guarantee section 44 retrieves 



reply information 50 n (see FIG. 5A) corresponding to the 
abnormal cutoff of connection from (a plurality of) reply 
information stored in the memory while using an IP address 
and a PORT number corresponding to the abnormal cutoff of 
5 connection as a key. 

In a step SE6 (or step SD7 in FIG. 2) , the transaction 
guarantee section 44 transmits reply information 90 n (see 
FIG. 7B) corresponding to the reply information 50 n to the 
transaction notification agent 34 n of the client 30 n . This 

10 notification reply information 90 n is received by the 
transaction notification agent 34 n . 

Following this, the transaction notification agent 
34 n determines the judgment result of a step SFl show in 
FIG. 4as 'Yes' . InastepSF2, the transaction notification 

15 agent 34 n retrieves notification reply information 90„ 
corresponding to the abnormal cutoff of connection f romamong 
a plurality of reply information stored in the memory while 
using the client application name (or request ID) of the 
received notification reply information 90 n as a key. In 

20 a step SF4, the transaction notification agent 34i makes 
transaction matching based on the reply data in the 
above-stated notification reply information 90 n . 

In this embodiment, description has been given to a 
case where the reply information is retrieved in the step 

25 SE5 shown in FIG. 3 and the notification reply information 



corresponding to the retrieved reply information is 
transmitted to the transaction notification agent. 
Alternatively, all the reply information stored in the memory 
may be transmitted to the transaction notification agent 
5 without making a retrieval as seen in a step SG5 shown in 
FIG. 6. Steps SGI to SG4 shown in FIG. 6 correspond to the 
steps SE1 to SE4 shown in FIG. 3. 

As stated above, according to this embodiment, the 
notification reply information is transmitted to the clients 

10 3d to 30 n and stored in the memory, and the notification 
reply information is transmitted to the clients 30i to 30 n 
when abnormality occurs to connection . Thus, compared with 
conventional rollback from the clients 30i to 30 n , network 
traffic can be reduced and communication load at a time when 

15 abnormality occurs to communication can be reduced. 

Furthermore, if connection is normally released, the 
reply information stored in the memory is destroyed. Thus, 
it is possible to enhance efficiency for utilizing the 
memory . 

20 In addition, since the request ID is included in the 

notification reply information, the request ID 
corresponding to the abnormal cutoff of connection can be 
easily specified based on the request ID and transaction 
matching can be made following the abnormal cutoff of 

25 connection. 



A preferred embodiment according to the present 
invention has been described in detail with reference to 
the drawings so far. The concrete examples of the 
constitution of the invention should not be limited to this 
5 embodiment and any changes in design within the scope of 
the invention are included in the invention. 

For example, a data communication program for 
realizing the functions of the server 40 may be recorded 
on a computer readable recording medium 200 shown in FIG. 
10 8, and the data communication program recorded on the 
recording medium 200 may be read and executed by a computer 
100 shown in FIG. 8 to thereby realize the functions of the 
server 40. 

The computer 100 shown in FIG. 8 consists of a CPU 
15 (Central Processing Unit) 101 executing the above-stated 
data communication program, an input device 102 such as a 
keyboard, a mouse or the like, an ROM (Read-only Memory) 
103 storing various data, an RAM (Random-access Memory) 104 
storing operation parameters and the like, a reader 105 
20 reading the data communication program from the recording 
medium 200, an output device 106 such as a display, a printer 
or the like, and a bus BU mutually connecting the constituent 
elements of the computer 100. 

The CPU 101 reads the data communication program 
25 recorded on the recording medium 200 through the reader 105 



and then executes the data communication program, thereby 
realizing the functions of the server 40 stated above. The 
recording medium 200 may be a transmission medium, such as 
a network, temporarily holding data as well as a portable 
type recording medium such as an optical disk, a floppy disk 
or a hard disk. 

As stated so far, according to the present invention, 
the reply information is transmitted to the external device 
and stored in the memory, and the reply information is 
transmitted to the external device when abnormality occurs 
to connection. Thus, compared with conventional rollback 
from the external device, the present invention has 
advantages in that the traffic of a communication line can 
be reduced and that communication load can be reduced when 
abnormality occurs to communication. 

Moreover, the present invention has an advantage in 
that efficiency for utilizing the memory can be enhanced 
since the reply information stored in the memory is destroyed 
if connection is normally released. 

In addition, according to the present invention, the 
identification information for identifying requests is 
included in the reply information. Due to this, the present 
invention can advantageously specify a request 
corresponding to the abnormal cutoff of connection and make 
transaction matching following the abnormal cutoff of 



connection . 

Although the invention has been described with respect 
to a specific embodiment for a complete and clear disclosure, 
the appended claims are not to be thus limited but are to 
5 be construed as embodying all modifications and alternative 
constructions that may occur to one skilled in the art which 
fairly fall within the basic teaching herein set forth. 
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